-
Notifications
You must be signed in to change notification settings - Fork 647
Link QNN backend to pybinding lib when built #13467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess rest of the pybind code was already present?
When all of the required libraries and environment variables are set up, it will work with only this change. I would like to further simplify, as there is a lot of setup required - including some copying around of python extension binaries. But this code here is enough to make it runnable in conjunction with the existing QNN CI scripts (which do all of the setup). |
Can you elaborate? |
Yeah, it looks like it's currently building the Python extension components separately and then copying them into the ET directory. (See https://docs.pytorch.org/executorch/main/backends-qualcomm.html#aot-ahead-of-time-components). As part of the build cleanup and pybind enablement, I'll see if I can fold that into our "main" pybind build. That will also make it just work with installation, wheels, etc. |
They should be part of |
Add (unquantized) QNN test flows to the nightly CI. This runs both the model and operator suite.
Sort of. It does expect that you're running scripts from the root directory of executorch (or have an editable install), since it puts the extension binaries in the source directory. So it won't work if you're using ET from another directory, such as a dependent project. It should ideally put these binaries wherever the installed copy of the executorch python package is. If no objection, I'm happy to take this task as part of the build workstream. Basically, running install_executorch.sh with qnn enabled will automatically do what that build.sh script does as part of the main install, in order to make it easy. |
This change makes it possible to run QNN models with pybindings, when enabled. It does still require the environment setup described in the docs.
I validated this change locally by running install_executorch.sh with CMAKE_ARGS="-DEXECUTORCH_BUILD_QNN=ON", and then lowering and running a simple add model. The CI set up further in this stack also leverage this feature and test it extensively.